Using Keyboard Behaviors

Introduction

A Java 3D Keyboard behavior responds to AWT key press events (KeyEvent.KEY_PRESSED and KeyEvent.KEY_RELEASED) and modifies the 4x4-transformation matrix within a TransformGroup. The changes to the TransformGroup can effect the size, position and rotation of the TranformGroupÆs child Nodes.

Keyboard navigation is typically used to simulate moving the viewer of a 3D scene, as opposed to manipulating individual objects within a scene. Mouse behaviors are usually used for object manipulation and are the subject of the next section, although there is considerable overlap between the two areas.

In terms of visual effect there is no difference between moving the viewer (by attaching the keyboard behavior to a TransformGroup on the View side of the scenegraph) and moving the scene itself (by attaching the keyboard behavior to a root TransformGroup on the scene side of the scenegraph).

As a reminder here is a diagram of the typical scenegraph structure that illustrates these two approaches:

figure 1. A Java 3D scenegraph. A Keyboard behavior can either be added to the scene side of the scenegraph (left) or to the View side of the scenegraph (right).

There are advantages and disadvantages to both approaches. If the keyboard behavior is added on the scene side of the scenegraph you really are moving the scene. For a single View and with a single ViewPlatform this will not be noticeable, however once there are multiple Views of the scene or predefined Views have been set up using numerous ViewPlatforms the effects of moving the scene will be noticeable.

The advantage of attaching the behavior to the scene side of the scenegraph is that most Keyboard behaviors expect this to be the case (including the built in behavior). Remember that the inverse of the multiplication of the Transform3Ds above the ViewPlatform is used to set the View projection matrix. A typical symptom of this is that if the Keyboard behavior is added on the View side of the scenegraph the motion and rotation keys are reversed.

If you need to support multiple Views you will want to add the Keyboard behavior to the View side of the scenegraph and modify the behavior to account for the reversal in movement direction. Otherwise it will probably be easier to add the behavior to a root TransformGroup on the scene side of the scenegraph.